The ability of computer systems to store and process information has transformed the way we live and work. Computer systems are more capable than ever, now commonly store a variety of sensitive data (e.g., financial information, personal documents, photos, passwords and other credentials, etc.) and perform a host of processing tasks utilizing that data. Additionally, most modern computer systems are coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data. With the amount of sensitive data stored on computer systems, and the increased connectedness of computer systems, there is more motivation than ever for nefarious parties to attempt to breach computer system security. For example, these parties may seek to utilize the sensitive data stored on those systems for their own purposes (e.g., to steal it, to encrypt it and use it as a ransom, etc.), may seek to hijack use of computer system resources, or may attempt to otherwise exploit or deceive users in other ways.
Accordingly, computer system manufacturers and software vendors continually seek new ways to harden computer system security. One such mechanism is Secure Boot. Secure Boot is a security standard developed by members of the computing industry to make sure that a computer system boots using software that is trusted by the computer manufacturer from the time the computer system is powered on to a defined point in an operating system startup. Using Secure Boot, every phase of an operating system boot process is measured and secured using secrets (e.g., encryption keys). For example, when a computer system first starts, its Secure Boot compliant firmware checks the signature of the boot manager that is to be loaded, as well as any firmware drivers that are to be loaded. If these signatures are good, the boot manager loads load an operating system loader of a target operating system (e.g., WINDOWS, Linux, UNIX, etc.) and verifies that it is properly signed too. This process continues with the operating system loader verifying the signature of boot drivers and the operating system kernel itself. An operating system that has booted in accordance with Secure Boot provides guarantees that the system is booted with software components that have been validated. Additionally, it can utilize secrets obtained during the boot process to attest to third party software (e.g., anti-malware software) that it was securely booted, and to provide measurements (e.g., a log of components loaded during the boot) taken during the boot process.
Another mechanism for hardening computer system security is to continually discover and patch security vulnerabilities in software, and to release updated versions of the software. This includes discovering and patching security vulnerabilities in operating systems. While some operating system components (e.g., services, drivers, etc.) can potentially be updated while the operating system is running (e.g., “hot patching” components by updating and restarting only those components), updating other core components, such as the kernel, has historically required a full reboot of the computer system itself. Rebooting a computer system is disruptive to the workload executing on the computer system, which is particularly inconvenient in server environments in which processes running on the computer system provide services to other computer systems.
To address this shortcoming, some operating systems vendors have developed mechanisms for updating core operating system components, such as the kernel, without requiring a full computer system reboot. In some implementations, such as kernel software reboot (KSR) from MICROSOFT CORPORATION, the currently executing operating system loads a new version of one or more operating system components (such as an operating system loader component, a new kernel, boot drivers, etc.) in memory, and directly begins execution of those components, without performing a full system reboot. Such in-place update/restart mechanisms can restart an updated operating system more quickly than doing a full system reboot, which reduces interruptions to workloads executing on the computer system.
However, when an operating system that was started in accordance with Secure Boot is replaced using mechanisms such as KSR, the newly started operating system loses the security assurances provided by Secure Boot. Specifically, there is no way to guarantee that the new operating system running on the system is genuine and has not been compromised. Also secrets that had been retrieved from Secure Boot components during the original hardware boot might have been compromised or leaked. Accordingly, there is an inherent incompatibility between Secure Boot and in-place operating system update mechanisms, which results in system administrators having to choose between use of Secure Boot and use of in-place operating system update mechanisms.